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REMARKS 

Claims 1-1 3 and 25-34 were rejected under 35 USC § 1 12, first paragraph, as failing to 
comply with the written description requirement. Claims 1-13 and 25-34 were also 
rejected under 35 USC § 101 as being directed to non-statutory subject matter. 

5 

Claims 14-24 were allowed. 

Claims 1, 25, 30, 33 and 34 are being amended to more clearly recite specific technology 
in the body of the rejected independent claims to overcome the 35 USC § 101 rejection. 
1 0 For example, a computer-controller counter and computer-readable attribute trees and 
inputs are now being recited to refer to specific technology, i.e., a computer. Applicant 
thus is reciting specific technology in the body of the claims, not just the preamble, and is 
not claiming nothing more than abstract ideas. Applicant therefore requests that the 35 
USC § 101 rejection be withdrawn. 
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Use of pre-programmed computers to carry out various functions for a trade at an 
electronic exchange is described in the specification, such as: 

The negotiations may even be carried out by computer programs that follow pre-programmed 
rules, (spec, page 3, lines 8-9) 

20 35 USC § 112 Rejection 

Examiner noted that claims 1-13 recite such limitations as buyer attribute input and seller 
attribute input that are not specifically described in the specification. For method claims 
25-29, there is no correlation between a computer and the recited steps. In claims 30-32, 
25 recited limitations such as a buyer attribute tree generator, a base product means, a seller 
attribute tree generator, an attribute tree comparator, and an overlap maximizer are not 
clearly defined or described in the specification. In claims 33-34 the claims recite a 
counter, yet no such limitation is clearly described in the specification. Applicant 
respectfully disagrees. 
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Method claims 25-29 are being amended to more clearly recite correlations between the 
computer and recited steps. 

Inputting attributes can be explicit or implicit. The client can explicitly specify attributes: 

5 Every node 2-1 0 of the tree represents an attribute name and value. Any path from the root of the 

tree to a leaf 20 specifies a single product. This path is a path of attribute names and values. In the 
case of a tree with explicit attributes (where the client has explicitly specified the attributes and 
values) one could load the root of the tree with the "basic product value"(BPV) that the TP 
specifies for the product. The edges are labeled with delta-values 12 (+ or -) by which the TP 
1 o modifies the product value when the subpath from the root 1 to the node at the end of the edge is 

chosen. For example, in figure 1, the Delta Product Value (DPV) from node 1-2 is +30, while the 
DPV from node 1-6 is the sum of DPVs from 1-2, 2-6 - +30 -30 = 0. The DPV at the leaf of the 
tree specifies the DPV along the entire path from the root to that leaf. (Spec page 10, lines 17-27, 
emphasis added) 

Implicit input of attributes such as by reading tables on seller web sites is described on 
page 11 of the specification. Thus input of attributes by the buyer or seller, either 
implicitly or explicitly, is described in detail in the specification. The recited buyer 
attribute input and seller attribute input are specifically described in the specification. 

Enablement of attributes is further evident by programming code that was attached to the 
provisional application referred to in the specification: 

The Attribute data structure and the associated operators are shown in the attached code of the 
provisional application. (Spec, page 9, lines 13-14) 

Java interface classes and pseudo code were attached to the provisional application. (Spec, page 
19, line 17) 

Certainly a copy of Java classes and pseudo-code is evidence of enablement. 

An example of steps for building (generating) an attribute tree is show in the specification 
on pages 12-1 3 and Figs. 4-5. A block diagram of an attribute-tree builder (generator) is 
shown in Fig. 4 and described in the specification: 

Figure 4 is a block diagram of an attribute-tree builder. Statistical system 48 reads relational 
35 data tables 40, 42, 44, which may be located on seller web sites. Online Analytical Processing 

(OLAP) system 46 may also be used to mine the data in relational tables 40, 42, 44 to determine 
delta values and attributes that determine the price of products in a product family. Systems 48, 46 
then populate attribute trees 49. (Spec, page 12, lines 22-26, emphasis added) 

40 Heuristics may even be used for generating sparse attribute trees: 

To avoid creating an exponentially large tree, heuristics may be used to create a sparse, but yet, 
reasonable representative of the tree. Standard statistical sampling techniques may be used to do 
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this. Figure 5 shows one embodiment of a heuristic to create an attribute tree. (Spec, page 12, line 
28 to page 13, line 2) 

The attribute tree can be for a buyer or for a seller. Thus the specification describes in fair 
5 detail (2 Figures and over 2 pages) a buyer attribute tree generator and a seller attribute 
tree generator. 

When there are multiple sellers, sellers of simiiar items can be searched for: 

Here the bidder can pick between multiple sellers who are selling "similar" products but different 
1 0 support for attributes that the bidder cares about. The bidder looks for a product whose attributes 

have the most overlap with the attributes the bidder cares about and bids on that/those produces). 

A bidder Bi looking for a product P finds several sellers auctioning the product in various 
configurations, steps 102, 104. For each seller, the seller's attribute tree is compared to the buyer's 
1 5 attribute tree, steps 108, 109. The attribute names, values, and ranges may not exactly match, so 

they may need to be normalized. (Spec page 18, lines 1-9) 

The similar items are similar to the base product desired by the buyer. Thus the 
specification described the "base-product means for searching for sellers that are offering 
20 the base product for sale" recited in claim 30. 

The relative ease of comparing attribute trees is described in the specification: 

The inventors* multi-attribute model is well-suited for electronic exchanges. The attribute trees 
provide a way to express the many options or configurations of products in a product family. The 
25 attribute tree is a convenient mechanism to receive, store, and compare multiple product 

configurations from many buyers and sellers. The attribute tree is a simple yet powerful structure 
for storing many attributes of a product family. (Spec, page 19, lines 19-23) 



30 



Thus the recited attribute tree comparator is described in the specification. 



The maximum overlap is found by comparing attribute trees: 



For each seller, the seller's attribute tree is compared to the buyer's attribute tree, steps 108, 109. 
The attribute names, values, and ranges may not exactly match, so they may need to be 
normalized. The degree of overlap detected in step 110 is stored for that seller. The attribute tree 
35 comparison is repeated for the other sellers with the same buyer's attribute tree, steps 1 12, 106- 

1 10. The maximum overlap is found, step 1 14. The maximum overlap indicates an optimal 
product configuration by one of the sellers that most closely matches the desired configurations of 
the buyer. (Spec page 18, lines 7-14, emphasis added) 

40 Thus the overlap mazimizer recited in claims 30-32 is described in the specification. 

Incrementing a counter for an attribute value is described on page 18, lines 28-29, with 
reference to step 140 of the procedure of Fig. 10: 
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When the buyer has entered an attribute value Vjt for attribute Aj, a counter for that attribute value 
is incremented, step 1 40. 

Indeed, even alternative embodiments of the counter are described: 

5 The increment of the counter can be by more than I, or a negative increment (decrement) can be 

substituted. Non-binary counting schemes such as Gray Code can be substituted. Rather than 
incrementing the counter, the value that the buyer places on an attribute can be summed. (Spec, 
page 20, lines 5-9) 

1 0 Thus the counter of claims 33-34 is described in the specification. 

Applicant thus requests that the under 35 USC § 1 12, first paragraph, rejection be 
withdrawn. 

1 5 In view of the above, it is submitted that claims 1-28, as amended, are in a position for 
allowance. This application was filed with formal drawings that have not been amended. 
Applicant believes that a full and complete response to the office action has been made. 
Reconsideration and re-examination is respectfully requested. Allowance of the claims at 
an early date is solicited. 
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If the Examiner believes that a telephone interview would expedite prosecution of this 
application, she is invited to telephone the undersigned at (831) 476-5506. 

Respectfully Submitted, 
Stuart T. Auvinen JS ^^^t ^ yf 

429 26th Avenue yUjZ^Dy^ 
Santa Cruz, CA 95062 ZJ^\JJ^^ 

Stuart T. Auvinen 

(83 1 ) 476-5506 Agent for Applicant 

(831) 477-0703 Fax Reg. No. 36,435 
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